系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄
前面二十四天，我已經陸陸續續透露了不少：
所以今天沒有什麼驚人的揭露。我只是要把它完整說一次，說清楚：
這三十篇文章的草稿是 Claude 寫的。這個工具的程式碼絕大部分是 Claude 和 GSD 寫的。
我提供的是：真實經歷、事實核對、專業判斷、以及決定要講什麼、不講什麼。
這件事值得誠實面對：我完全可以不寫這篇。
我可以把 Day 08、09、10 都改成「我發現問題、我分析原因、我修好了」。可以把五條規則寫成我的原創。可以讓整個系列看起來像一個資深工程師獨力打造一個開源工具的故事。
沒有人會查證。而且那個版本大概更符合大家對「鐵人賽參賽者」的期待。
所以為什麼不？
這是最實際的理由，不是道德理由。
回想 Day 10 那篇。第一版草稿寫的是「我」分析手機跑版的 CSS、找出四個原因、逐一修好。
看起來很專業。但它是一篇沒有靈魂的技術文章。 網路上有一萬篇教你 RWD 怎麼修的文章，寫得都比那版好。
而真實版本是：朋友傳截圖給我，我轉手貼給 Claude 說「你去修」。
這個版本才有東西。 因為它揭露了一個 2026 年真實存在但很少被誠實描述的工作型態。
同樣的模式在別的地方也一樣：
| 假的版本 | 真的版本 | 哪個有價值 |
|---|---|---|
| 我設計了五條對話規則 | 規則來自 GPT，我判斷它們在現場撐不撐得住 | 後者（多模型協作 + 判斷力的價值） |
| 我從一開始就設計了結構性紀律 | 稽核之後才發現我的樹早就在做這件事 | 後者（架構的意外紅利） |
| 我遇到 API 政策風險，架構救了我 | 我沒被影響純粹是運氣，不是設計 | 後者（風險的真正形狀） |
| 我測過小模型但缺數據 | 我根本沒測 AI 對話那塊 | 後者（引出兩個缺口同源的發現） |
每一次修正成真相，文章都變好了。沒有一次例外。
這讓我懷疑那些「看起來比較厲害」的敘事，本質上是在用可信度換取形象。
我報的組別是 Claude AI 組。
如果一個講 Claude 協作的三十天系列，隱瞞了自己就是 Claude 協作的產物——那不只是不誠實，是論述上的自相矛盾。
我在 Day 12 到 Day 15 花了四天論證：紀律要靠結構、假設要靠稽核變成事實、把假設當事實是最容易犯的錯。
然後在自我描述上造假？那前面四天就白寫了。
這一點可能是最有爭議的，但我想講清楚我的立場。
工具存在的意義就是讓人更有效率。
我做 IT 二十年，從來沒有人要求我「不能用 nmap，要手動 ping 每個 IP 以展現專業」。沒有人說「不能用監控系統，要親自巡機房」。
沒有人會要求木匠不用電鋸，以展現手工精神。
那為什麼「用 AI 寫程式」需要遮掩？
我猜是因為程式碼曾經是專業能力的證明，而現在它不完全是了。這個轉變讓人不安，我理解。
但不安不等於應該假裝它沒發生。
這是我覺得最該認真回答的問題，因為它決定了這整個系列有沒有價值。
我把它拆成四項：
這個工具解決的問題，是我在台灣、越南、柬埔寨二十年現場工作累積出來的。
「AI 太會回答卻不會排障」（Day 02）不是一個查資料查到的洞見，是我打開 ChatGPT 問網路問題、得到一份十五條清單、然後意識到它幫不上忙的那個下午。
AI 可以寫出解法。但問題必須有人在現場撞到。
那五條規則要不要採用，判斷標準只有一個：放進真實的 IT 服務台，撐不撐得住？
規則很便宜。判斷哪條規則在現實裡活得下來，不便宜。
這個工具刻意不做的功能，跟它做了的功能一樣重要：
AI 很擅長做更多。決定不做什麼，需要有人承擔後果。
Day 21 那個 200 行的決定，Claude 可以分析技術風險，但「使用者在柬埔寨工廠現場點開一個空白節點」的代價有多重——那個判斷是我的，因為那個現場我待過。
Day 24 列了五個修正。每一個都是「這件事不是這樣發生的」。
而它們的共同點很值得注意：Claude 錯的方向，全部都是讓故事更符合常規敘事。 每一個錯誤都比真相「更合理」。
在一個 AI 能把任何素材寫得很流暢的世界裡，「知道那天到底發生了什麼」是唯一不能被生成的東西。
我不想把這篇寫成一個「我想清楚了」的結論，因為有一件事我還沒想清楚。
如果我的貢獻主要是判斷力，那判斷力是怎麼來的？
我的判斷力來自二十年的現場——來自我親手 ping 過的 gateway、換過的網路線、凌晨三點修過的伺服器。來自我曾經做過那些現在可以被外包的工作。
那麼下一代的工程師，如果從一開始就把實作外包給 AI，他們的判斷力從哪裡來？
我不知道。
我確定的只有一件事：我今天能有效地使用 AI，是建立在我曾經沒有 AI 的二十年上面。 而這件事不可複製。
這不是在說年輕人不行——他們會發展出我想像不到的能力。但我不會假裝我知道那條路長什麼樣。
核心 vs 外部
核心是「這個工具解決了真實問題，而且有人在用」。誰寫的程式碼是外部細節。
已成立 vs 假設
「隱瞞會讓系列看起來更厲害」是假設。
「每次修正成真相文章都變好」是我在寫這三十篇的過程中驗證過的事實——五次，零例外。
可控 vs 不可控
我控制不了讀者怎麼看「AI 協作」這件事。
我控制得了自己寫的東西是不是真的。
後者是我唯一真正擁有的東西。
我原本以為這篇會很難寫，因為它像是在承認什麼。
寫完之後發現不是。它比我想的容易，因為我沒有什麼要承認的。
我沒有假裝過我是一個前端工程師。我從 Day 01 就說我是 IT 基礎建設出身。我沒有假裝這個工具是我一個人寫的——我從 Day 08 就在寫「丟給 Claude」。
這篇只是把散在二十四天裡的東西，收攏成一句話：
這是一個二十年 IT 現場工程師，用 AI 當實作手，做出一個真的有人在用的工具，然後誠實地記錄整個過程。
如果這個故事沒有說服力，那它就不該有說服力。
Day 21 到 Day 25，這一章的主題是「另外那 64%」：
這章最重要的一句話： 明確的原則，是委派的前提——不管你委派的對象是 AI 還是人。
下週預告（最後一章）： 前面二十五天都在講「做」。最後五天講「之後」——第一個陌生人回報的 Bug、Fork 為什麼比 Star 多、為什麼我選企業授權而不是 SaaS、以及一個做了三十天的人回頭看到的東西。
作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣
iThome鐵人賽
看影片追技術